그냥 쉬어가는 페이지인데 parquet 에 대해서 곰곰히 생각을 좀 해보면요.. 얘는 컬럼 기반 파일 구조인데 컬럼별로 오프셋을 이용하여 적층형으로 되어 있습니다.
예를 들어 필드가 5개이면 파일의 구조는 종방향(레코드 방향으로)으로 1번 필드 전부, 2번 필드 전부, 3번 필드 전부... 이렇게 스태킹 되어 있어요
유리한 점이 뭐냐 하면 3번 필드가 age라 치고 select * from kk where age=33 이라고 할 때 3번 필드 위치까지 종방향 오프셋 점프해서 스캔해서 키 매핑만 참조하면 되니까 매우 효율적이 됩니다. 즉, 하이브 쿼리 같은 걸로 건바이건 조회를 하거나 스팍 데이터 프레임에서 필드 관측을 통해 처리할 때는 효율적이 됩니다. (저수준으로 보면 SSD가 아닐시 디스크 헤드의 이동 거리가 짧고 로캘리티 덕에 캐시 힛팅이 늘어나며 최소 단위 읽기에 있어서 블럭 캐시의 힛팅률이 극단적으로 향상됩니다. 한번에 퍼오는 최소 청크 단위가 있는데 그 안에 필요한 데이터가 있을 확률이 높으므로)
그런데 우리 엔진의 경우를 살펴보면, 모든 레코드의 모든 필드를 매쳐가 다 관측해야 하는 구조입니다. 건바이 건으로 도는게 아니라 전체 세그를 처리합니다. 즉 줄바이줄로 첫번째 MR을 돌리게 되고, 줄의 전체 (전체 필드)가 대부분 필요하므로 파일 리더 쪽에서는 오프셋을 정신없이 돌아다녀야됩니다. (저수준으로 보면 SSD가 아닐시 하드 헤드가 앞뒤앞뒤위아래위아래 뺑이를 쳐야 할 뿐만 아니라, 앞에서 설명한 L1, L2, 커널 캐시 힛트 등이 무용이 됩니다) 따라서 parquet로 처리하면 하이브 쿼리 기반 잡에 있어서는 효율적이 되나 엔진 측면에서는 페널티가 있다고 유추해 볼 수 있습니다.
... 술이 덜깼군요 ...